In data communication networks, service function chaining and service function forwarding can be used for forwarding of data packets along a predetermined service function path through the network. Internet Engineering Task Force (IETF) Request for Comments (RFC) document 7665, entitled “Service Function Chaining (SFC) Architecture,” October 2015 and referred to herein as RFC 7665, describes various aspects of service function chains, service functions, service function paths, service function forwarders, and service nodes. According to RFC 7665, a Service Function Chain may define an ordered set of abstract Service Functions (SF) and ordering constraints that must be applied to packets and/or flows selected as a result of classification. Also according to RFC 7665, a SF is responsible for specific treatment of received packets, and can be realized as a virtual element or be embedded in (instantiated upon) a physical network element. For example, a SF can be implemented using a virtual function instantiated in the network (e.g. within a virtual machine instantiated in a data center, or within a container created within a computing platform) or using a physical node configured to perform the service function. Also according to RFC 7665, a Service Function Path (SFP) is a constrained specification of where packets assigned to a certain service must go.
A draft IETF RFC document entitled “Network Service Header,” (draft-ietf-sfc-nsh), available via https://tools.ietforg/html/draft-ietf-sfc-nsh-05, describes a Network Service Header (NSH) carried by a packet which can provide service function path identification and can be used by NSH-aware functions such as service function forwarders and service functions. The NSH can also carry data plane metadata. A service function forwarder (SFF) is responsible for forwarding traffic to one or more service functions in an SFP according to information carried in the NSH.
IPv6 packet headers include a 128-bit source address field, a 128-bit destination address field, and other fields labelled as IP version, traffic class, flow label, payload length, and next header fields. The source address and destination address fields include a routing prefix portion composed of a global prefix portion and a subnet prefix portion, and an endpoint identifier portion. The source and destination addresses are intended to identify the source network device from which the packet originated and the destination network device for which the packet is intended respectively. Similar address fields (and an IP version field) exist in an IPv4 packet header.
Existing approaches for handling packets according to service function chaining can require specialized equipment to implement. Such approaches can also be limited in their ability to: convey ancillary information or metadata; perform adaptive routing within the service function domain; and/or use other conventional packet forwarding mechanisms. Examples of conventional packet forwarding mechanisms include equal cost multipath selection, load balancing, source routing and fast path restoration. Therefore there is a need for a method and apparatus for forwarding packets along a service function path in a service domain that obviates or mitigates one or more limitations of the prior art.
This background information is provided to reveal information believed by the applicant to be of possible relevance to the present invention. No admission is necessarily intended, nor should be construed, that any of the preceding information constitutes prior art against the present invention.